home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 914 < prev    next >
Encoding:
Text File  |  1996-08-06  |  2.9 KB  |  78 lines

  1. Path: sunsite.doc.ic.ac.uk!demon!ittpub.nl
  2. From: wil@ittpub.nl (Wil Evers)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: How to ... declare a virtual static function in a class ?
  5. Date: Mon, 08 Jan 1996 10:35:29 GMT
  6. Distribution: world
  7. Message-ID: <821097329.18975@ittpub.nl>
  8. References: <30EFAC88.13DF@worldcom.ch>
  9. NNTP-Posting-Host: ittpub.nl
  10. X-NNTP-Posting-Host: ittpub.nl
  11.  
  12. In article <30EFAC88.13DF@worldcom.ch> ean-Pierre Schnyder  
  13. <jschnyde@worldcom.ch>Jean-Pierre Schnyder <jschnyde@worldcom.ch> writes:
  14.  
  15. > Hi,
  16. > I guess this is not possible. Any idea on the rationale about this 
  17. > limitation ? Thanks, Jean-Pierre
  18. > -- 
  19.  
  20. About half a year ago, there was an interesting discussion about this on  
  21. comp.std.c++. Basically, a static virtual function call would resolve to  
  22. an overloaded version in a derived class (if defined) when called through  
  23. a pointer or reference to an object `myObject->staticVirtual()' and  
  24. statically resolved when called by explicit qualification  
  25. `MyClass::staticVirtual()'. Like an ordinary static member function, it  
  26. would not have a `this' pointer, so it cannot directly access the object  
  27. on which it was called, even when called through an object  
  28. pointer/reference.
  29.  
  30. Some arguments against it were (I'm sure there were more, but these are  
  31. the ones I remember):
  32.  
  33. 1. Since a static member function doesn't have a `this' it seems  
  34. counterintuitive to allow dynamic resolution.
  35.  
  36. 2. (Bjarne Stroustrup in his book on the Design an Evolution of C++:) the  
  37. proponents of static virtual member functions typically have only one  
  38. application in mind: run-time type information. The language already has  
  39. another mechanism to support this.
  40.  
  41. 3. Static virtual member functions can easily be simulated by having a  
  42. pair of functions instead of just one:
  43.  
  44. class Base {
  45. public :
  46.     static void staticFn();
  47.     virtual void dynamicFn() const
  48.         { return staticFn(); }
  49. };
  50.  
  51. class Derived : public Base {
  52. public :
  53.     static void staticFn();
  54.     virtual void dynamicFn() const
  55.         { return dynamicFn(); }
  56. };
  57.  
  58. (Here, dynamicFn() calls a particular version of staticFn() depending on  
  59. the dynamic type of the object it was called for. But note that  
  60. dynamicFn() *can* access the object for which it was called, which is more  
  61. than a static virtual would be able to do, so the simulation is not  
  62. perfect.).
  63.  
  64. 4. Problems in defining what a pointer to a static virtual member function  
  65. should do. Should it keep its dynamic resolution property, when we don't  
  66. know it advance if it will be used in a static or dynamic context?
  67.  
  68. The discussion became very confusing when people started asking for static  
  69. virtual data members or even plain virtual data members.
  70.  
  71. One of the proponents of static virtual member functions, Don Organ  
  72. (donorgan@ix.netcom.com) had the courage to actually submit a proposal to  
  73. the ANSI committee. The proposal came rather late, and I'm not sure if it  
  74. has actuallly been included in the C++ standardization process.
  75.  
  76. - Wil
  77.